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ABSTRACT 

Air  Force  Research  L aboratory  ( AFRL)  research¬ 
ers  at  the  Aerospace  Vehicle  Technology  As¬ 
sessment  and  Simulation  (AVTAS)  Laboratory  are 
currently  conducting  the  Open  Control  Platform 
(OCP)  Hardware-ln-The-Loop  (HITL)  project 
sponsored  by  the  DARPA  Software  Enabled  Con¬ 
trol  (SEC)  Program.  The  purpose  of  this  project  is 
to  develop  the  capability  to  be  an  OCP  test-bed 
and  to  evaluate  the  OCP  controls  and  simulation 
environment  for  a  specific  test  case.  The  OCP  pro¬ 
vides  an  open,  middleware-enabled  software 
framework  and  development  platform  for  develop¬ 
ers  of  distributed  and  embedded  software  applica¬ 
tions.  The  middleware  isolates  the  programmer 
from  the  details  of  the  operating  system  and  pro¬ 
vides  a  mechanism  for  communication  with  other 
OCP  software  components  A  Traffic  Collision 
Avoidance  System  (TCAS)  was  chosen  as  a  rep¬ 
resentative  flight  controls  application  to  exercise 
OCP.  The  programmatic  approach  taken  by  the 
OCP-HITL  project  is  a  series  of  simulation  experi¬ 
ments  with  increasing  complexity.  The  first  simu¬ 
lation  was  an  “all  software”  simulation,  conducted 
in  August  2002.  A  portion  of  the  “all  software 
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simulation”  was  then  migrated  to  a  VME  based 
system  running  VxWorks.  A  readiness  review  of 
the  HITL  simulation  was  conducted  in  March  2003 
in  preparation  for  the  actual  testing  scheduled  for 
the  May  2003  timeframe.  This  readiness  review 
tested  a  2  ship  non-co-operating  scenario,  a  2  ship 
cooperating  s  cenario,  a  nd  a  p  ilot-in-the-loop  s  ce- 
nario.  Future  testing  is  planned  for  formation  flight 
and  fault  injection  scenarios 


INTRODUCTION 

The  OCP  is  a  software  infrastructure  being  devel¬ 
oped  by  the  Boeing  Corporation  sponsored  by  the 
DARPA  SEC  Program.  It  is  intended  to  enhance 
the  ability  to  develop  and  test  control  algorithms 
which  will  eventually  execute  in  embedded  soft¬ 
ware  within  Uninhabited  Air  Vehicles  (UAVs).  The 
OCP  supports  distributed  computing  and  commu¬ 
nication  allowing  heterogeneous  components  to 
interoperate  across  platforms  and  network  proto¬ 
cols  while  dealing  with  tight  constraints  on  band¬ 
width,  response  time,  and  reliability.  By  using 
OCP,  control  engineers  can  concentrate  on  the 
controls  problem  at  hand  without  having  to  worry 
about  the  details  of  component  connectivity.  The 
“middleware”  design  of  OCP  isolates  the  operating 
system  and  the  underlying  hardware  allowing 
development  and  testing  to  take  place  on  system 
architecture  different  from  the  final  target.  The 
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well-defined  interfaces  inherent  with  an  OCP  de¬ 
sign  facilitate  efficient  partitioned  software  devel¬ 
opment  and  insure  a  relatively  painless  final  inte¬ 
gration. 

The  HITL  simulation  using  OCP  was  designed  to 
evaluate  some  of  the  key  OCP  principles.  1.  Archi¬ 
tecture  isolation/independence  -  The  simulation 
incorporated  three  different  system  architectures; 
Window  2K  on  a  PC,  Linux  on  a  PC,  and  VxWorks 
on  a  PowerPC.  2.  Ease  of  porting  -  The  simula¬ 
tion  was  initially  built  and  tested  as  an  “all  soft¬ 
ware”  simulation.  The  process  initially  running  on 
the  Windows  2K  platform  was  migrated  to  the 
HITL  3.  Partitioned  software  development  -  Three 
teams  were  involved  in  the  development  of  the 
simulation.  The  Boeing  team  provided  OCP  sup¬ 
port  and  in  particular  provided  key  support  on  the 
integration  of  the  PowerPC  into  AVTAS’s  architec¬ 
ture.  The  Northrop  team  developed  all  of  the  com¬ 
ponents  associated  with  the  Traffic  Alert  and  Colli¬ 
sion  Avoidance  System  (TCAS)  algorithms  and 
the  aircraft  models  utilized  in  the  simulation.  The 
AVTAS  team  built  the  OCP  components  neces¬ 
sary  to  interface  the  facilities  Infinity  Cube  Simula¬ 
tor  to  the  OCP  HITL  simulation. 

This  paper  will  first  provide  an  introduction  to  OCP 
followed  by  a  discussion  on  the  models  and  the 
TCAS  algorithms  employed  in  the  simulation.  The 
simulation  architecture  and  scenarios  will  then  be 
presented.  The  paper  will  conclude  with  results  of 
the  testing  to  date  and  future  plans  for  the  pro¬ 
gram. 

OCP  INTRODUCTION 

The  O  CP  p  rovides  a  n  open,  m  iddleware-enabled 
software  framework  and  development  platform  for 
developers  of  distributed  and  embedded  software 
applications.  The  middleware  layer  of  the  OCP 
provides  the  software  layer  isolating  the  applica¬ 
tion  software  from  the  underlying  compute  plat¬ 
form.  It  provides  services  for  controlling  the  exe¬ 
cution  and  scheduling  of  software  components, 
mediating  inter-component  communication,  and 
enabling  distribution  of  application  components 
onto  a  target  system.  The  OCP  includes  innova¬ 
tive  scheduling  techniques,  adaptive  resource 
management,  and  support  for  dynamic  reconfigu¬ 
ration. 

The  OCP  is  being  developed  by  the  Embedded 
Systems  Research  Team  within  Boeing  Phantom. 
Assisting  B  oeing  in  these  e  fforts  are  the  Georgia 
Institute  of  Technology,  Honeywell  Labs,  and  the 
University  of  California,  Berkeley.  The  OCP  is 


being  delivered  to  a  host  of  university  and  indus¬ 
trial  researchers  who  are  participating  in  the 
DARPA  SEC  Program. 

OCP  OVERVIEW  AND  BACKGROUND 

The  OCP  is  composed  of  many  elements,  dis¬ 
cussed  in  later  sections,  which  enable  the  rapid 
generation  a  nd  test  of  e mbedded  a  nd  d  istributed 
software  application  programs.  Included  among 
these  elements  are: 

1 )  a  middleware  software  infrastructure  com¬ 
ponent, 

2)  a  Controls  API  that  allows  for  tool-based 
software  architecture  specification  and  auto¬ 
coding  of  a  software  framework  that  implements 
the  specification,  and 

3)  an  integration  with  useful  controls  devel¬ 
opment  tools,  software  tools,  and  simulation  tools. 
The  software  infrastructure  component  has  its 
heritage  in  the  CORBA  [1]  (Common  Object  Re¬ 
quest  Broker  Architecture)  based,  Boeing-funded 
software  initiative  called  Bold  Stroke.  Under  the 
Bold  Stroke  initiative,  CORBA  and  its  attendant 
object  technologies  were  leveraged  as  a  prime 
enabler  for  re-use  of  software  components  across 
product  lines,  and  for  rapid  re-implementation  of 
existing  solutions  on  changing  and  evolving  com¬ 
puting  hardware  and  operating  system  platforms  - 
primary  considerations  in  achieving  affordable  avi¬ 
onics  software  development. 

Boeing,  in  prior  flight  demonstrations  on  multiple 
types  of  aircraft,  has  successfully  demonstrated 
application  of  this  CORBA  technology  in  the  do¬ 
main  of  non-safety  critical  mission  processing, 
which  required  hard  real  time  performance  in  tasks 
that  ran  at  rates  up  to  40  Hz.  One  of  the  goals  of 
OCP  is  to  bring  the  advantages  of  object  oriented 
programming  and  CORBA  to  the  domain  of  UAV 
multi-level  flight  control.  The  application  of 
CORBA  in  this  domain  introduces  new  challenges 
for  the  OCP  that  have  spawned  new  requirements 
for  OCP  services.  Challenges  include:  1)  faster 
rates,  2)  the  need  to  ensure  vehicle  stability,  3) 
highly  accurate  timing  in  sensor  processing,  and, 

4)  achievement  of  hard  deadlines  at  flight  control 
rates.  Candidate  software  infrastructure  services 
have  been  implemented  in  the  OCP  to  meet  these 
challenges. 

OCP  MIDDLEWARE 

The  middleware  of  the  OCP  can  be  used  to  fuse 
embedded  and  distributed  system  application 
software  components  together,  controlling  their 
execution  and  communication. 
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A  primary  motivating  factor  in  implementing  a  mid¬ 
dleware-based  architecture  was  the  promise  of 
isolating  the  application  components  from  the  un¬ 
derlying  platforms.  This  allowed  for  a  more  cost- 
effective  path  for  implementing  common  software 
components  that  could  be  used  (1)  across  differ¬ 
ent  product  lines,  and  (2)  could  be  rehosted  onto 
evolving  embedded  computing  platforms.  Support 
for  rapid  re-implementation  of  existing,  tested  de¬ 
signs  onto  evolving  computing  platforms  is  impor¬ 
tant  for  maintaining  an  effectiveness  advantage  in 
currently  fielded  embedded  systems. 

These  evolving  computing  platforms  are  starting  to 
be  dominated  by  commercial  hardware  and  soft¬ 
ware  components,  which  have  more  dynamic  life- 
cycles  than  previous  military  components,  and 
which  create  more  opportunities  for  incorporation 
of  computing  advances  into  existing  systems.  Fur¬ 
ther,  more  commercial  and  military  flying  platforms 
are  experiencing  longer  lifetimes,  and  the  ability  to 
inexpensively  re-host  existing  functional  and 
tested  software  on  updated  computing  platforms  is 
very  attractive. 

The  embedded  software  framework  of  the  OCP 
inherits  the  RT-CORBA  (Real  Time-CORBA) 
based  middleware  of  Bold  Stroke.  The  inherent 
advantages  of  a  middleware-based  solution  within 
OCP  should  prove  to  be  an  enabler  for  current  and 
future  embedded  and  distributed  software  devel¬ 
opments. 


Figure  2.  Distributed  Processing  and  Inter- 
Component  Communications 

The  ability  of  the  OCP  to  isolate  application  com¬ 
ponents  from  the  underlying  system  also  can  be 
used  to  enable  efficient  embedded  and  distributed 
system  software  development.  For  initial  design 
and  development,  application  code  integrated  with 
the  OCP  middleware  can  be  executed  on  familiar 
desktop  systems,  such  as  those  using  Windows  or 
Linux  operating  systems.  Certain  levels  of  soft¬ 
ware  testing  can  take  place  more  conveniently  on 
the  desktop.  Then,  the  operating  system  and 
hardware  isolation  features  of  the  middleware 
would  be  instrumental  in  implementing  the  smooth 
transition  of  the  developed  embedded  application 
code  to  the  embedded  hardware  target  -  perhaps 
a  target  executing  a  POSIX-compliant  Real-Time 
Operating  System  (RTOS),  such  as  VxWorks  or 
QNX.  Isolation  o  f  the  a  pplication  w  ould  result  i  n 
minimal  code  changes  during  transition  to  the  em¬ 
bedded  target. 


Use  of  the  CORBA-based  middleware  helps  iso¬ 
late  application  software  components  from  the  un¬ 
derlying  hardware  and  operating  systems  in  the 
computing  platform.  The  resulting  layered  archi¬ 
tecture  is  illustrated  in  Figure  1 . 
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Figure  1 .  OCP  Layered  Architecture 


The  middleware  also  facilitates  distributed  proc¬ 
essing  and  inter-component  communications  by 
supporting  CORBA  event-based  communication, 
as  illustrated  in  Figure  2. 


The  middleware  of  OCP  is  being  designed  so  that 
it  offers  the  embedded  software  developer  a  rich 
set  of  features  desirable  for  real-time  applications. 
These  features  include  dynamic  scheduling;  adap¬ 
tive  resource  management;  dynamic  reconfigura¬ 
tion;  hybrid  system  mode  switching  support;  and 
convenient  access  to  real-time  triggers. 

Embedded  applications  built  with  the  OCP  mid¬ 
dleware  exhibit  a  layered  architecture,  as  shown  in 
Figure  3.  The  bottom  software  layer  shown  is  that 
of  the  operating  system  (OS).  The  OCP  has  been 
designed  to  allow  applications  to  be  executable  on 
a  variety  of  OSs,  including  desktop  non-real  time 
Windows  a  nd  L  inux,  a  s  well  as  R  T OSs,  s  uch  a  s 
VxWorks  and  QNX. 

The  OS  portability  is  enabled  with  the  next  highest 
layer,  an  OS-abstraction  layer  implemented  by  the 
open-source  Adaptive  Communications  Environ¬ 
ment  (ACE)  software.  ACE  provides  common  OS 
services  to  software  residing  in  the  layers  above  it. 
Software  in  these  upper  layers  can  access  useful 
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OS  services  with  ACE  calls,  and  ACE  then  trans¬ 
lates  the  requests  into  OS-specific  requests. 

The  advantages  of  CORBA  are  made  accessible 
in  OCP  by  the  next  highest  I  ayer,  the  T  AO  (The 
ACE  ORB)  layer.  TAO  and  ACE  are  available  as 
open  source  implementations  from  Washington 
University  in  St.  Louis.  TAO  has  been  developed 
as  an  ORB  (Object  Request  Broker)  implementa¬ 
tion  that  is  portable  across  a  variety  of  underlying 
compute  platforms.  TAO  itself  provides  some 
real-time  performance  extensions  to  CORBA. 


Develop  Reusable 
-  , .  Application  Components  ' 


'  DevelopJReusable 
"Architecture  Framework 


Board  Support  Package 

ZU 


Figure  3.  Layered  Architecture  of  an  OCP-Based 
Application 

Above  the  TAO  layer,  the  OCP  middleware  pre¬ 
sents  to  the  application  a  rich  set  of  run-time  ser¬ 
vices,  many  of  them  based  on  standard  CORBA. 
On  top  of  ACE  and  TAO,  some  real-time  perform¬ 
ance  extensions  were  developed  by  Boeing,  under 
the  Bold  Stroke  project,  and  utilized  in  fighter  air¬ 
craft  Mission  Management  embedded  software. 
The  OCP  includes  further  real-time  performance 
support  to  handle  the  requirements  of  UAV  con¬ 
trol.  Some  of  the  more  important  services  are  dis¬ 
cussed  below. 

CORBA  Services  (Real-Time  Publish  /  Sub¬ 
scribe) 

The  CORBA  event  channel  (EC)  can  be  used  to 
route  data  between  software  components  without 
resorting  to  parameter  passing  or  global  memory 
pools,  both  of  which  are  difficult  to  design  and 
maintain  for  applications  distributed  over  multiple 
threads,  p  rocesses,  a  nd  p  rocessors.  D  ata  b  eing 
generated  by  a  software  component,  if  it  is  needed 
elsewhere  in  a  system,  can  be  published  over  the 
EC.  Other  software  components  in  the  system 
which  have  access  to  the  ORB,  and  which  need  a 
particular  input,  can  subscribe  through  the  EC  for 
that  input.  The  software  component  publishing  the 
data  (as  an  output)  and  the  one  or  more  software 


components  subscribing  to  that  data  (as  an  input) 
can  reside  anywhere  the  ORB  exists  --  in  the 
same  process,  in  different  processes  within  the 
same  computer,  on  different  computers  within  the 
same  chassis,  on  different  computers  at  different 
locations  (e.g.,  two  different  vehicles,  or  a  vehicle 
and  a  ground  station),  etc. 

TheCORBAECcanalsobeu  sed  t  o  t  rigger  the 
execution  of  a  software  component  based  on  pro¬ 
files  of  arriving  inputs.  This  can  be  used  to  relieve 
the  software  designer  from  trying  to  derive  a  cor¬ 
rect  cyclic  executive  that  hopefully  satisfies  all  in¬ 
put  data  dependencies  correctly,  which  can  be  a 
daunting  task  for  applications  that  have  large 
numbers  of  application  software  components, 
have  multiple  threads,  which  span  more  than  one 
process,  and  which  span  more  than  one  proces¬ 
sor. 


OCP  Services  (Resource  Management) 

The  OCP's  Resource  Management  component 
provides  a  mechanism  for  controlling  and  making 
better  use  of  compute  resources  in  the  executing 
system.  The  OCP  resource  management  compo¬ 
nent  is  an  extension  of  the  Honeywell  Labs  Real 
Time  Adaptive  Resource  Management  (RT-ARM) 
capability.  [2]  With  RT-ARM,  it  is  possible  to  spec¬ 
ify  quality  of  s  ervice  ( QoS)  i  nformation  a  bout  t  he 
various  software  components  in  the  system.  An 
example  QoS  specification  would  be  the  allowable 
rates  of  execution  for  the  proper  operation  of  a 
software  component.  While  the  system  is  in  op¬ 
eration,  the  RT-ARM  functionality  can  adapt  the 
scheduling  behavior  of  the  system  to  optimize 
utilization  of  the  finite  embedded  compute  re¬ 
sources  based  on  the  software  components  which 
are  currently  active  and  their  QoS  information. 
The  resulting  execution  rates  of  the  components, 
as  scheduled  by  the  RT-ARM  capability,  are 
communicated  to  the  individual  software  compo¬ 
nents  so  that  they  can  then  modify  their  behavior 
based  on  their  assigned  rate  (e.g.,  modify  control¬ 
ler  gains).  RT-ARM  makes  use  of  the  TAO  sched¬ 
uling  component  [3]. 

OCP  Services  (Hybrid  Systems  Mode  Change 
Support  --  the  Transition  Service) 

A  hybrid  system  combines  both  continuous  and 
discrete  elements.  For  example,  in  a  typical  flight 
controls  system,  the  lower  levels  of  the  architec¬ 
ture  tend  to  be  designed  as  continuous  time  con¬ 
trollers.  When  moving  to  higher  levels  of  the 
architecture,  controllers  tend  to  be  of  the  discrete 
supervisory  type.  The  composite  system  can 
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function  like  a  pseudo-continuous  controller  able 
to  operate  in  one  or  more  distinct  modes. 

To  help  meet  the  needs  of  this  hybrid  system  phi¬ 
losophy,  system  mode  support  has  been  added  to 
the  OCP  with  the  Transition  Service.  Each  system 
mode  can  be  characterized  as  being  made  up  of  a 
specific  profile  of  active  (and  inactive)  software 
components,  a  specific  QoS  profile  for  the  active 
components,  and  a  specific  profile  of  input/output 
interconnections  between  active  components. 
The  Transition  Service  allows  components  to  iden¬ 
tify  the  current  mode  of  the  system,  allows  com¬ 
ponents  to  trigger  m  ode  changes,  a  nd  a  Hows  for 
smooth  mode  transitions  at  appropriate  times  of 
system  operation  (e.g.,  after  inner-loop  control 
actuator  command  writes). 

Note  also  that  for  each  system  mode,  a  different 
profile  of  QoS  p arameters  can  be  specified  for  a 
software  component.  This  provides  a  powerful 
way  to  allow  use  of  RT-ARM  to  make  the  best  use 
of  available  on-board  resources,  since  some  com¬ 
ponents  are  more  critical  in  some  system  modes 
and  would  therefore  have  their  more  challenging 
resource  demands  reflected  in  their  QoS  specifica¬ 
tion  for  those  modes. 

OCP  Services  (Accurate  Time  Triggering  --  the 
Timer  Service) 

UAV  flight  control  applications  have  stringent  real¬ 
time  constraints  on  operation.  For  example,  flight 
control  sensor  sampling  must  be  accomplished  at 
precise  time  intervals,  with  very  little  frame-to- 
frame  jitter  and  without  missing  a  sample.  The 
Timer  Service  in  the  OCP  provides  a  way  to  accu¬ 
rately  trigger  a  software  component  based  on 
time.  This  is  accomplished  by  providing  a  conven¬ 
ient  API  linking  a  physical  real-time  clock  on  the 
embedded  processor  board  to  a  software  compo¬ 
nent  execution  trigger. 

OCP  Services  (Performance  Optimizations) 

Performance  optimizations  are  being  implemented 
in  the  OCP  to  reduce  the  amount  of  time  that  an 
OCP-based  application  spends  in  the  CORBA- 
based  middleware  layer.  These  optimizations  in¬ 
clude  use  of  light-weight  EC  events,  client-side 
caching  to  reduce  the  need  for  data  passing  in  a 
distributed  application,  and  the  ability  to  allow  effi¬ 
cient  protocols  to  be  plugged  into  the  ORB  to  op¬ 
timize  data  transfer  speeds  between  specific  com¬ 
ponents. 

OCP  CONTROLS  API 


As  m  entioned  previously,  t  he  O  CP  p  rovides  s  ev- 
eral  advanced  mechanisms  such  as  adaptive  re¬ 
source  management,  reconfiguration  during  mode 
switches,  and  access  to  highly  accurate  timing 
sources  for  component  triggering.  To  help  hide 
the  complexity  of  these  features  from  the  controls 
designer,  and  to  shield  the  controls  designer  from 
C++  or  object  oriented  programming,  the  OCP 
includes  the  Controls  API  --  a  controls  designer 
abstraction  layer  above  the  RT  CORBA  implemen¬ 
tation.  This  API  allows  the  designer  to  focus  on 
familiar  tools  and  terminology  whilst  enabling  the 
use  of  RT  CORBA  extensions.  This  abstract  layer 
was  a  collaborative  Boeing  -  Georgia  Tech  effort. 
The  Controls  API  provides  an  interface  for  manag¬ 
ing  OCP  components,  setting  system  information, 
and  controlling  system  execution. 

The  Controls  API  allows  a  software  system  de¬ 
signer  to  lay  out  the  system  graphically  using  the 
popular  Simulink  tool.  Here,  the  designer  speci¬ 
fies  the  software  component  names,  their  inputs 
and  outputs,  and  the  interconnections  with  inputs 
and  outputs  of  other  components. 

This  initial  layout  is  then  decorated  with  additional 
information  by  the  system  designer  using  another 
graphical  tool  written  in  Java.  Here,  all  other  per¬ 
tinent  information  about  the  software  system  is 
specified.  This  other  information  includes  specifi¬ 
cation  of  system  modes,  the  active  software  com¬ 
ponents  and  their  interconnections  in  each  mode, 
QoS  information  for  active  components  in  each 
mode,  specifications  of  which  components  get 
triggered  by  highly  accurate  timers,  allocations  of 
components  to  different  processes,  etc.  The  com¬ 
pleted  system  model  is  then  sent  to  the  final  por¬ 
tion  of  the  Controls  API  for  automatic  generation  of 
a  C++  framework  that  will  trigger  software  compo¬ 
nents  based  on  the  system  model,  that  will  route 
inputs  and  outputs  based  on  the  model,  and  that 
will  allow  system  mode  changes  as  specified  in 
the  model.  The  autogenerated  framework  con¬ 
tains  placeholders  in  the  code  for  the  controls  de¬ 
signer  to  insert  the  code  for  the  individual  software 
components. 

OCP  INTEGRATION  WITH  CONTROLS  DEVEL¬ 
OPMENT  TOOLS  AND  SIMULATION  TOOLS 

The  OCP  provides  integration  with  popular  and 
useful  controls  and  software  design,  development, 
and  testing  tools.  Commercial  tools  like  Microsoft 
Visual  C++,  Microsoft  Visual  Debugger,  the 
VxWorks  real-time  operating  system,  and  Mat- 
lab/Simulink  have  wide  acceptance  in  the  software 
and  controls  communities.  Buildable  and  runnable 
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examples  delivered  with  the  OCP  to  illustrate  OCP 
features  make  use  of  these  well-supported  com¬ 
mercial  products.  The  debugger  can  be  used,  for 
example,  during  a  running  vehicle  simulation  to  set 
breakpoints,  single-step,  and  perform  other  useful 
testing  functions  while  simulation  displays  show 
the  dynamic  state  of  the  vehicle. 

TCAS  OVERVIEW 

Over  the  course  of  the  HITL  program,  there  has 
been  a  growing  emphasis  on  automated  collision 
avoidance.  As  a  result,  logic  from  the  commer¬ 
cially  packaged  software,  TCAS  algorithm,  was 
used  as  a  base  model  for  the  design  of  a  mission 
manager.  The  basic  TCAS  algorithm  consists  of 
two  main  components.  The  first  component  de¬ 
tects  and  alerts  pilots  to  possible  vehicle  conflicts, 
while  the  second  computes  an  advised  rate  of 
climb  to  remove  the  threat.  Since  the  vehicle  be¬ 
ing  u sed  i n  the  H ITL  s  imulation  i s  an  u  nmanned 
vehicle,  the  pilot  advisory  is  converted  into  a  4-D 
waypoint  command  which  drives  a  “fly  to  point 
within  time”  outer  loop  guidance  routine. 

NON-CO-OPERATING  TCAS 

The  TCAS  detection  algorithm  monitors  the  inertial 
position  and  velocity  of  intruder  vehicles  in  the  sur¬ 
rounding  area.  Using  this  data  it  calculates 
whether  any  pose  a  threat  of  collision  or  near  miss 
(based  on  a  user  specified  separation  in  both  the 
horizontal  and  vertical  planes.  TCAS  then  uses  an 
estimated  time  to  the  Closest  Point  of  Approach 
(CPA)  as  a  guideline  for  prioritizing  threats.  A  time 
variable  concept,  simplified  tau  (xu),  was  devel¬ 
oped  to  give  an  approximation  of  the  time  to  CPA 
by  dividing  slant  range  by  the  closing  speed 
(range/range  rate)  in  the  xy-plane.  The  tau  time 
constant  is  used  to  ensure  that  there  is  ample  time 
to  maneuver  out  of  danger, 

r 

Tu  =  7 

r 

Equation  1  -  Simplified  tau  time  constant 

The  threshold  value  for  xu  is  predetermined  based 
on  the  maneuverability  of  the  vehicle.  When  the 
calculated  value  drops  below  this  threshold  the 
intruder  is  considered  a  threat  in  the  horizontal 
plane  and  is  evaluated  to  see  if  it  also  breaches 
the  vertical  separation  threshold.  The  simplified 
tau  evaluation  only  sets  a  threshold  for  time  which 
cause  problems  when  detecting  intruders  with 
slow  closure  rates.  If  the  relative  horizontal  closure 
rate  is  slow  enough,  an  intruder  vehicle  can  get 
well  within  the  desired  minimum  distance  separa¬ 


tion  before  it  is  recognized  as  a  threat.  In  order  to 
include  t  ime  a  nd  d istance  constraints,  a  distance 
threshold  (Dm)  constant  is  added  to  the  simplified 
tau  equation  giving  the  Bramsom  Tau  Criteria  (tb), 
which  protects  the  vehicle  from  failure  due  to  slow 
closure  rates. 


f  IT 

Equation  2  Bramsom  tau  time  constant 

Once  it  has  been  established  that  an  intruder  will 
breach  the  horizontally  protected  space,  TCAS 
uses  both  tau  values  ( tUi  tb)  to  determine  if  the 
intruder  will  also  breach  the  vertical  separation 
desired.  Due  to  the  fact  that  altitude  data  from  on 
board  transponders  are  in  discrete  altitude  steps 
of  100  feet,  TCAS  creates  a  critical  area  to  evalu¬ 
ate  whether  the  intruder  will  breach  the  vertical 
safety  area.  Two  vertical  separation  estimates  are 
calculated  using  each  of  the  tau  time  constants: 

mvi=(zo-Zi)+'tu(zo-zi) 

mv2  =(zo-zi)+Tb(z0-zi) 

Equations  3  &  4  -  Vertical  separation  estimates 

z0,  Z;  =  altitude  of  own  vehicle  and  intruder 
z0 ,  Zj  =  rate  of  climb  of  own  vehicle  and  intruder 

Once  the  calculated  separation  value  of  mv1  or  mV2 
dips  below  the  user  specified  threshold,  the  in¬ 
truder  is  considered  a  collision  threat.  Each  in¬ 
truder  that  breaks  this  threshold  is  arranged  in  or¬ 
der  of  their  corresponding  tau  from  least  to  great¬ 
est  and  then  sent  to  the  avoidance  algorithm  for 
de-confliction.  A  sequence  diagram  of  the  detec¬ 
tion  process  is  shown  in  figure  4. 
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Figure  4  -TCAS  Detection  Sequence  Diagram 

The  list  of  intruders  is  then  sent  to  the  avoidance 
algorithm  where  it  is  used  to  map  out  multiple 
paths  using  a  branching  node  method.  User  pre¬ 
defined  possible  rates  of  climb  are  used  to  create 
these  paths.  The  first  node  is  designated  as  the 
position  of  the  ownship  vehicle,  while  each  set  of 
following  nodes  are  set  by  the  next  smallest  tau 
until  all  intruders  are  considered.  The  number  of 
total  possible  paths  is  based  on  the  number  of 
predetermined  rates  of  climb  along  with  the  num¬ 
ber  of  intruders: 

#  paths  =#  rates  of  climb*' 

Equation  5  -  Total  Possible  Paths 

A  cost  algorithm  is  then  used  to  evaluate  which 
path  causes  the  ownship  vehicle  to  deviate  the 
least  from  its  current  path  while  still  achieving  the 
desired  difference  in  altitudes  between  the  vehi¬ 
cles.  Each  node  has  a  cost  associated  with  it  de¬ 
termined  by  the  estimated  separation  distance 
from  the  intruder  at  CPA.  The  farther  from  the  in¬ 
truder  the  node  is,  the  greater  the  cost.  This  is  true 
unless  the  node  breaks  the  minimum  clearance 
threshold,  in  which  case  the  node  is  given  an  ex¬ 
tremely  high  cost  essentially  removing  it  and  all  of 
its  sub  paths  from  the  list  of  possible  avoidance 
maneuvers.  Once  each  node’s  cost  has  been 
evaluated,  the  overall  cost  of  each  path  is  calcu¬ 
lated  by  summing  the  node  costs,  which  it  passes 
through.  The  path  with  the  least  cost  is  the  one 
chosen  by  TCAS. 


Figure  5  -  TCAS  Avoidance  Sequence  Diagram 

The  branching  node  method  is  illustrated  in  Figure 
6,  which  depicts  the  avoidance  algorithm  given 
three  possible  rates  of  climb  and  three  intruders 
breeching  the  minimum  clearance  distance.  There 
are  a  total  of  27  possible  paths  for  the  vehicle  to 
evaluate.  The  circle  surrounding  each  intruder  is 
the  defined  bubble  of  safe  separation.  All  17  of  the 
paths,  which  pass  through  these  bubbles,  are  as¬ 
signed  a  high  cost  and  are  represented  by  the 
dashed  lines.  Of  the  remaining  10  paths,  the  bold 
path  is  determined  to  be  the  least  expensive. 


Seconds 

Figure  6  -  TCAS  Avoidance  Example 

Since  the  tau  variable  is  based  on  time  to  CPA 
and  not  actual  distances,  the  protected  volume  of 
each  incidence  varies  based  on  the  speeds  and 
headings  of  the  aircraft  involved.  These  are  the 
limiting  factors  of  TCAS.  The  maximum  rate  of 
closure  that  it  can  protect  against  is  1200  knots 
horizontally  and  10,000  ft/min  vertically. 


7 

American  Institute  of  Aeronautics  and  Astronautics 


Since  the  original  intention  of  TCAS  is  to  be  an 
advisory  program,  there  were  modifications  nec¬ 
essary  to  convert  it  to  a  mission  manager.  The  first 
change  needed  was  to  output  4-D  waypoints  to 
drive  the  outer  loop  guidance  routine,  instead  of 
an  advisory  rate  of  climb.  To  accomplish  this,  the 
mission  manager  uses  the  commanded  rate  of 
climb  combined  with  the  time  to  CPA  calculated  by 
TCAS  to  estimate  the  altitude  that  the  vehicle  must 
achieve  to  avoid  the  threat.  This  altitude,  along 
with  the  mission  targets  x,  y  positions,  provide  the 
point  to  fly  to  for  the  guidance  routine  and  the  mis¬ 
sion  targets  Estimated  Time  of  Arrival  (ETA)  filled 
in  the  time  used  to  control  the  speed.  During 
these  initial  testing,  the  TCAS  algorithm  would  turn 
on  and  off  multiple  times  as  the  vehicle  change  its 
rate  of  climb  in  an  attempt  to  obtain  the  com¬ 
manded  altitude.  The  results  were  a  degradation 
in  the  performance  of  the  collision  avoidance.  To 
reduce  the  frequency  of  this  cycling,  two  control 
timers  were  added  to  the  system.  The  first  timer 
holds  the  initial  TCAS  command  once  an  evasive 
maneuver  is  commanded.  This  allows  time  for  the 
vehicle  to  respond  to  the  request  before  re¬ 
evaluating  the  situation.  The  second  timer  defines 
the  length  of  time  that  the  command  is  held  after 
the  threat  has  past  before  TCAS  can  turn  off.  The 
top-level  I  ogic  of  the  overall  mission  manager  in¬ 
cluding  these  modifications  are  displayed  in  Figure 
7.  The  detection  and  avoidance  sequence  dia¬ 
grams  are  represented  by  the  blocks  titled  “Detect” 
and  “Avoid”  respectively.  The  two  added  timers 
are  referred  to  as  the  “On  Timer”  and  the  “Hold 
Timer”. 


Figure  7  -  Modified  TCAS  Top-Level  Sequence 
Diagram 


CO-OPERATING  TCAS 

In  Scenario  2  of  the  HITL  program,  there  arose  the 
need  to  perform  a  coordinated  collision  avoidance 
maneuver.  To  achieve  vehicle  negotiation,  the 
cost  function  i  nternal  to  t  he  T  CAS  a  Igorithm  was 
modified  to  allow  communicated  data  to  b  e  u  sed 
during  its  evaluation.  The  cost  function  was  modi¬ 
fied  t  o  c  onsider  t  hree  f  actors.  T  he  f  irst  b  eing  the 
available  vehicle  states.  The  cost  function  does  a 
preliminary  evaluation  of  altitude  and  rate  of  climb 
of  each  vehicle  and  flags  a  recommended  com¬ 
mand  of  either  climb  or  dive.  For  ambiguous 
cases  (i.e.  vehicles  at  common  altitude  and  rate  of 
climb)  a  “right  of  way”  system  was  designed  to  use 
the  vehicles  longitudinal  and  lateral  coordinates  to 
resolve  the  issue.  This  removes  the  chance  of  two 
vehicles  initially  deciding  to  perform  the  same  ma¬ 
neuver.  This  recommendation  is  then  used  to  add 
a  gain  to  the  originally  calculated  cost  of  all  the 
rates  of  climb,  which  contradict  it.  The  gain  to  the 
function  effectively  raises  the  cost  of  the  maneuver 
removing  the  likelihood  of  being  chosen  while  still 
leaving  the  option  available  if  all  else  fails.  Next, 
the  cost  function  evaluates  the  communication 
data  being  sent  between  the  vehicles.  This  com¬ 
munication  is  specified  to  b  e  a  signal  w  hether  or 
not  the  other  vehicle’s  TCAS  is  actively  command¬ 
ing  a  collision  avoidance  maneuver  and  a  signal 
stating  what  that  commanded  altitude  is.  With  this 
information  the  cost  algorithm  calculates  a  better 
estimate  on  what  maneuver  is  required  to  achieve 
the  separation  desired.  The  last  modification  to 
the  cost  function  was  the  ability  to  set  altitude  con¬ 
straints  to  avoid  the  vehicles  being  commanded 
above  their  physical  flight  ceiling  or  driven  into  the 
ground,  which  was  a  problem  encountered  during 
early  tests. 

MODELS 

All  the  scenarios  tested  in  the  HITL  program  use 
two  base  vehicle  models.  The  ownship,  which  is 
run  HITL,  is  a  UAV  type  vehicle  while  the  intruder 
is  an  entirely  software  model  of  a  generic  fighter 
class  vehicle.  Each  vehicle  uses  a  generic  outer 
loop  controller  which  acts  as  an  autopilot  consist¬ 
ing  of  the  TCAS  mission  manager  described  ear¬ 
lier. 

The  introduction  of  the  pilot  to  the  simulation 
brought  many  new  issues  to  the  table.  The  first 
and  most  notable  was  the  fact  that  when  the  pilot 
disengaged  the  autopilot,  the  model  and  inner  loop 
became  unstable.  The  outer  loop  was  able  to  hide 
these  problems  but  the  pilot-in-the-loop  made 
these  deficiencies  very  apparent.  Another  prob- 
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lem,  which  arose  from  the  pilot  testing,  was  the 
case  of  severe  maneuvering  causing  the  vehicle  to 
slip  off  of  the  aero  data  tables  used  by  the  model 
causing  the  simulation  to  crash.  These  problems, 
which  otherwise  would  have  gone  unnoticed,  were 
fixed  resulting  in  a  much  more  robust  model  for 
future  use  on  HITL  and  other  programs. 

TEST  SCENARIOS 

Each  vehicle  in  the  HITL  simulation  is  broken  into 
eleven  separate  OCP  Components  (Figure  8). 
These  eleven  components  are  then  separated  into 
processes  based  on  the  hardware  architecture. 
Since  the  UAV  is  the  only  vehicle  to  be  flown 
HITL,  it  is  the  only  one  that  is  separated  into  two 
processes.  One  process  runs  the  controller  on  the 
hardware  and  another  updates  the  model  outside 
of  the  h  ardware  on  a  WinNT  machine.  All  other 
models  are  software  only  and  therefore  run  on  a 
single  process.  This  structure  is  used  as  the  basis 
for  the  HITL  programs  five  specified  software  test 
scenarios.  Each  of  these  scenarios  i  s  then  e  xe- 
cuted  under  multiple  collision  course  approach 
angles  (specifically  acute  and  obtuse).  By  running 
the  scenario  under  acute  and  obtuse  relative 
heading  conditions,  the  TCAS  algorithm  can  be 
tested  under  its  worst-cases:  the  extremes  of  high 
and  low  closure  rates.  The  case  of  low  rate  clo¬ 
sure  causes  the  intruder  vehicle  to  breach  the 
separation  threshold  d  esired  before  the  tau  crite¬ 
ria,  i  s  breached  a  nd  the  obtuse  case  causes  the 
closure  rate  to  test  the  upper  limits  of  TCAS. 


Pilot 

Command 


Figure  8  -  Block  Diagram  of  OCP  Components 


TEST  RESULTS 

The  first  scenario  successfully  tested  two  vehicles 
traveling  on  a  collision  course  and  the  ownship 
performs  an  evasive  climb  or  dive  to  avoid  the  in¬ 


truder.  In  this  scenario  there  is  no  communication 
between  the  vehicles  and  it  is  assumed  that  the 
intruder  is  blind  to  what  is  happening. 

In  the  second  scenario  tested,  both  vehicles  are 
equipped  with  the  TCAS  mission  manager.  The 
initial  collision  courses  are  the  same  as  the  first 
scenario  but  instead  of  the  ownship  taking  on  the 
full  responsibility  of  the  evasive  maneuver,  both 
vehicles  react  to  the  possible  collision.  The  com¬ 
munication  between  the  two  vehicles,  which  was 
not  present  in  the  first  scenario,  allows  the  vehi¬ 
cles  to  negotiate  a  coordinated  de-confliction  plan 
where  one  dives  and  the  other  climbs.  It  is  noted 
that  for  the  initial  instance  in  which  the  vehicles 
detect  a  collision,  each  vehicle  attempts  to  perform 
the  entire  de-confliction  alone.  Once  communica¬ 
tions  of  the  detection  between  the  vehicles  begin 
and  they  negotiate  a  solution,  each  vehicle  com¬ 
mands  half  of  the  change  in  altitude  required  to 
accomplish  the  desired  separation.  This  commu¬ 
nication  continues  throughout  the  maneuver  and  is 
updated  constantly  resulting  in  the  more  maneu¬ 
verable  vehicle  being  requested  to  do  more  of  the 
change  in  altitude.  This  is  seen  in  the  time  histo¬ 
ries  where  the  more  agile  generic  fighter  aircraft  is 
asked  to  perform  more  of  the  maneuver,  as  time 
goes  on  based  on  its  performance  response. 


Scenario  3  Commanded  Altitude 
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Figure  9  -  Scenario  2  Acute  Time  Histories 


Scenario  3  adds  a  human-in-the-ioop  aspect  to 
scenario  2  which  allowed  robustness  testing  of  the 
mission  manager.  (Scenario  3  is  discussed  in 
more  detail  in  the  next  section)  The  insertion  of  the 
pilot  allows  us  to  examine  the  reaction  of  the  mis¬ 
sion  manager  to  unanticipated  decisions  by  the 
other  vehicle.  The  ownship  has  to  react  to  an  in¬ 
truder  pilot  overriding  the  negotiated  T CAS  outer 
loop  command. 

The  final  two  scenarios  to  be  completed  are  add¬ 
ing  a  wingman  to  the  ownship  and  fault  injection. 
The  wingman  will  perform  basic  station  keeping 
abilities  while  only  communicating  with  the  own- 
ship.  The  ownship  will  be  the  intermediary  be¬ 
tween  the  intruder  and  the  wingman,  who  will  not 
directly  communicate  throughout  the  scenario. 
The  final  scenario  is  fault  injection  into  the  system. 
This  scenario  will  test  the  fault  detection  algorithm 
being  developed  as  well  as  the  reconfiguring  of 
the  vehicle’s  performance.  The  fault  injector  will 
be  another  component  added  to  the  architecture, 
which  will  insert  faults  into  the  model  as  data  is 
passed  to  the  fault  detection  isolation  component. 


Figure  10  -  Fault  Detection  Architecture 


Pilot-in-the-Loop  HITL  simulation 


The  pilot-in-the-loop  portion  of  the  simulation 
(scenario  3)  is  designed  to  evaluate  the  process  of 
integrating  an  OCP  based  simulation  into  the  AV- 
TAS  simulation  architecture  and  to  prepare  AV- 
TAS  as  a  future  OCP  test  bed. 

The  infinity  cube  simulator  is  a  state-of-the-art  fix 
based  research  simulator  containing  four  colli¬ 
mated  displays  in  a  cube  arrangement,  a  projected 
Heads  Up  Display  (HUD),  and  a  29”  monitor  for 
the  Heads  Down  Display  (HDD).  It  contains  a 
stick  and  throttle  and  a  set  of  generic  rudder  ped¬ 
als.  The  out  the  window  (OTW)  display  is  driven 
by  Subrscene,  a  locally  developed  image  genera¬ 
tion  software  package  that  runs  on  PC’s  under 
Linux.  Figure  1 1  shows  the  architecture  employed 
for  the  pilot-in-the-loop  simulation  from  the  OCP 
vantage  point 


Figure  11  -  Pilot-In-Loop-Architecture 

A  Windows  2k  platform  runs  OCP  processes  1,  3, 
and  5.  P  rocess  1  is  the  ownship  a ircraft  model. 
Process  3  contains  both  the  aircraft  model  and  the 
controller  for  the  intruder.  Process  5  communi¬ 
cates  with  a  Virtual  Battle  space  Management 
System  (VBMS)  server  to  update  VBMS  in  real¬ 
time.  One  Linux  platform  is  used  to  host  the 
VBMS  display  and  an  associated  CORBA  based 
VBMS  server.  A  second  Linux  platform  runs  OCP 
process  4  and  the  infinity  cube  I/O  process.  Proc¬ 
ess  4  interfaces  the  rest  of  the  OCP  simulation  to 
the  infinity  cube.  This  platform  will  be  discussed  in 
more  d  etail  i  n  s  ucceeding  paragraphs.  T  he  final 
platform  is  the  HITL  system  and  consists  of  a 
PowerPC  running  VxWorks.  The  controller  proc¬ 
ess  for  the  ownship  (Process  2)  is  run  on  this  plat¬ 
form.  All  machines  are  connected  to  a  dedicated 
Ethernet  network. 
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Scramnet 


Figure  12  -  Infinity  Cube  Interface 
Figure  12  shows  in  more  detail  how  the  OCP  por¬ 
tion  of  the  simulation  is  interfaced  to  the  infinity 
cube. 

Process  4  consists  of  two  OCP  components.  The 
Hands  On  Stick  And  Throttle  (HOT AS)  component 
is  responsible  for  providing  the  intruder  model  with 
the  stick,  throttle,  and  rudder  pedal  inputs  from  the 
infinity  cube.  The  analog  and  digital  signals  from 
the  stick,  rudder  pedals,  and  the  throttle  are  read 
via  a  K  eithley  I  /O  c  ard  b  y  t  he  1 10  p  rocess.  This 
process  then  places  the  data  into  SCRAMNet 
memory  where  it  is  read  by  the  HOTAS  OCP 
component  and  sent  to  the  intruder  model  via 
standard  OCP  signaling  mechanisms.  The  Subr- 
scene  component  receives  ownship  and  intruder 
state  information  via  OCP  signaling  mechanisms 
and  writes  this  information  into  SCRAMNet.  A  Vis¬ 
ual  Driver  process  running  on  another  Linux  plat¬ 
form  reads  the  state  information  from  SCRAMNet 
and  sends  it  to  Subrscene  via  Ethernet.  Subr- 
scene  is  run  across  4  Linux  based  platforms  with 
one  platform  per  infinity  cube  channel.  The  Subr¬ 
scene  OCP  component  also  sends  the  state  in¬ 
formation  to  two  other  Linux  platforms  over 
Ethernet.  These  platforms  generate  the  symbol¬ 
ogy  for  the  HUD  and  the  HDD. 

A  standard  HUD  is  being  used  with  a  modification 
to  annunciate  the  condition  when  TCAS  detection 
occurs.  An  existing  HDD  was  modified  to  include 
a  simple  vertical  and  horizontal  situation  display  to 
facilitate  re-acquiring  the  ownship  aircraft.  The 
intruder  model  is  set  up  to  blend  the  inputs  from 
the  stick  and  the  autopilot  for  stick  inputs  below  a 
certain  threshold.  When  the  stick  inputs  exceeded 
this  threshold  the  autopilot  is  disengaged.  The 


paddle  switch  at  the  base  of  the  stick  is  used  to  re¬ 
engage  the  autopilot. 

The  general  guidelines  for  running  scenario  3  with 
pilot-in-the-loop  are  to  allow  the  initial  avoidance 
maneuvers  to  take  place  and  then  try  to  re-acquire 
the  ownship  and  force  another  collision  avoidance 
situation.  Several  team  members  flew  the  simula¬ 
tion  in  preparation  for  the  readiness  review.  This 
initial  testing  showed  that  all  of  the  interfaces  were 
functioning  properly.  The  cube  display  system 
provided  a  compelling  view  of  the  initial  avoidance 
maneuvers  performed  by  TCAS.  Stick  and  throttle 
inputs  were  verified  to  be  correct  though  some 
difficulty  was  experienced  in  flying  the  intruder 
manually  due  to  the  aero  model  currently  being 
employed.  During  this  initial  checkout  the  ownship 
model  was  successfully  re-acquired  on  several 
occasions  and  performed  evasive  maneuvers  as 
expected. 

CONCLUSIONS 

The  HITL  simulation  utilizing  the  OCP  is  showing 
promising  results  at  this  point  in  the  project.  Soft¬ 
ware  developed  by  three  different  teams  is  being 
integrated  with  little  difficulty  due  to  the  well- 
defined  OCP  interfaces.  The  ownship  controller 
process  that  was  developed  and  tested  on  a 
Win2k  machine  was  easily  ported  to  a  VxWorks 
machine.  The  current  HITL  simulation  is  success¬ 
fully  running  on  a  heterogeneous  network  of  ma¬ 
chines. 

Testing  of  the  2-ship  non-co-operating,  the  2  ship 
co-operating,  and  the  pilot-in-the-loop  scenarios  is 
scheduled  for  May  2003.  Testing  of  the  formation 
flight  and  fault  injection  scenarios  is  scheduled  for 
late  summer  of  2003. 
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